perm filename BREAK.BUG[LSP,SYS] blob
sn#049042 filedate 1973-06-17 generic text, type T, neo UTF8
∂17-JUN-73 1433 FOO,DBA
Don't know when you will get this - more details on the BREAK problem.
It seems to be connected with interrupting (GO foo) statements. In this
case the OK or GO does not reset the break depth counter,and the break
is not properly released. The next interrupt of GO gives a depth of
one more, but doing ↑ causes one of two kinds of lossage:
1. xxxxxxx ILL MEM REF FROM UNBREAK0
(/BREAK1 BROKEN)
in which case the only escape is ↑↑ (which continues to work)
2. xxxxxxx ILL MEM REF FROM SETARG
NON-NUMERIC ARGUMENT
at which time the thing goes into a tight loop from which ther
is no escape.
If you don't tell me you have got this message soon, I'll try
Daryle Lewis at BBN.
In case anyone else reads this, the problem is as follows: funnies
when interrupting
(PROG NIL LBL (PRINC @FOO)(GO LBL))
If the (GO LBL) is interrupted then on doing OK or GO and another
interrupt, the second break thinks it is at a depth of 2. Now read
top of message down!